(19) 



J 



Europaisches Patentamt 
European Patent Office 
Office europeen des brevets 



(12) 



(43) Date of publication: 

13.05.1998 Bulletin 1998/20 

(21) Application number: 97308575.6 

(22) Date of filing: 28.10.1997 



( ii) EP0 841 618 A2 

EUROPEAN PATENT APPLICATION 

(51) mtci 6; G06F 9/46 



(84) Designated Contracting States: 


(72) Inventors: 


AT BE CH DE DK ES Fl FR GB GR IE IT LI LU MC 


• Cink, Kimberly Ann 


NL PT SE 


Rochester, Minnesota 55904 (US) 


Designated Extension States: 


• Newcombe, Russell Ley 


AL LT LV RO SI 


Round Rock, Texas 78681 (US) 


(30) Priority: 31.10.1996 US 741729 


(74) Representative: Jennings, Michael John 




IBM United Kingdom Limited, 


(71) Applicant: International Business Machines 


Intellectual Property Department, 


Corporation 


Hursley Park 


Armonk, N.Y. 10504 (US) 


Winchester, Hampshire S021 2JN (GB) 



(54) Method and apparatus for defining the scope of a search oparation 



(57) A method and apparatus for controlling a scope 
of location for a FactoryFinder object used by a program 
to find a factory object which is used to create another 
object in an object-oriented system. The scope of loca- 
tion may be a specific machine, all machines within a 
work group, all object server processes running under 
a particular operating system, etc. An abstract location 



interface is provided which is subclassed to provide a 
location object. The location object provides methods 
for returning a list of serve rs ; for returning a boolean val- 
ue of TRUE or FALSE for a specific server, and for cre- 
ating a new location object and registering servers that 
result from an intersection/union of the servers regis- 
tered with the current location and another location. 
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Description 

Field of the Invention 

The present invention relates to data processing 
systems, and more particularly, to defining the scope of 
a search operation such as is implemented by a COR- 
BAservices Factory Finder object in an object-oriented 
programming environment. 

Background of the Invention 

The development of application and system soft- 
ware for data processing systems has traditionally been 
a time-consuming and somewhat repetitive task, with 
software developers often having to write or rewrite 
code to perform well-known user interface and system 
functions in addition to writing the code utilized to imple- 
ment the desired new functionality. Recently, object-ori- 
ented programming (OOP) has emerged as a dominant 
new programming paradigm that enables the rapid de- 
velopment and implementation of functionality while 
permitting the customization and reuse of objects. 

The power of OOP as a software development phi- 
losophy is realized chiefly through object frameworks, 
which provide a collection of base object classes that 
can be selectively utilized by a system developer to cre- 
ate a software system, much like a hardware developer 
might construct a desktop computer from standard hard- 
ware components. Object frameworks are particularly 
advantageous when utilized within adistributed comput- 
ing environment in which multiple, possibly heterogene- 
ous, computer systems are interconnected to allow sys- 
tem hardware and software resources to be shared be- 
tween computer systems. In order to permit programs 
written in multiple diverse languages to utilize object 
classes defined within a single object framework, it is 
necessary to develop a minimum level of object stand- 
ardization, thereby enabling, at least to some degree, 
the interoperability of object-oriented software. One or- 
ganization that is working to establish industry guide- 
lines and object management specifications to provide 
a common object framework for application develop- 
ment is the Object Management Group (OMG). The 
specifications promulgated by OMG enable the reusa- 
bility, portability, and interoperability of object-based 
software in heterogeneous distributed computing envi- 
ronments (HDCE). An example of a commercially avail- 
able object framework that conforms to OMG specifica- 
tions is the Distributed System Object Model (DSOM), 
which is described, for example, in the "SOM Objects 
Toolkit version 3.0 Programmer's Guide, Volume 1: 
SOM and DSOM", available from International Business 
Machines Corporation. 

The Object Management Group (OMG) defines an 
industry standard for Life Cycle Services in "COR- 
BAservices: Common Object Services Specification", 
OMG Document No. 95-3-31 . Within the OMG Life Cy- 



cle Services standard, a number of object-oriented pro- 
gramming interfaces are defined in support of the crea- 
tion and destruction of objects within a heterogeneous 
distributed computing environment (HDCE). Among the 
5 interfaces introduced within the OMG Life Cycle Serv- 
ices standard is the FactoryFinder interface, which pro- 
vides a standard service that can be utilized by applica- 
tions to locate a Factory object (i.e., an object that is 
used to create instances of other objects) within the het- 
erogeneous distributed computing environment (HD- 
CE). 

The OMG FactoryFinder interface introduces an op- 
eration called fi nd_f actor ies, which returns an Inter- 
face Definition Language (IDL) sequence of Factory ob- 
jects that satisfy input criteria specified within a 
factory_key input parameter. In heterogenous distribut- 
ed data processing systems that contain hundreds or 
thousands of objects, of which many may satisfy a par- 
ticular factory_key, the number of Factory objects re- 
turned in the sequence can be large. Consequently, the 
user may desire to restrict the scope of the FactoryFind- 
er find_factory method to a specific set of servers in 
order to control which factory objects are returned. 

Although controlling the behaviour of the Factory- 
Finder method by restricting activities to a specific loca- 
tion scope is highly desirable, the OMG specifications 
do not define a standard interface which enables a user 
to specify a location scope. Although location scope 
may be encapsulated within a FactoryFinder object, 
each FactoryFinder object would have to have a unique 
implementation, and modifying the scope at runtime 
would not be a simple matter. Consequently, it would be 
desirable to provide an interface capable of defining a 
location scope, and more particularly, an interface com- 
patible with the OMG FactoryFinder interface that may 
be used as the scope of FactoryFinder operations. It is 
also desirable to be able to associate a location object 
with a FactoryFinder object, or any number of Factory- 
Finder objects, in order to enforce a location scope for 
the behaviour of the FactoryFinder object or objects. 

Summary of the Invention 

According to a first aspect, the invention provides a 
method, implemented in a computer system, for creat- 
ing an interface for defining the scope for searches for 
object factories in an object oriented environment, in- 
cluding the steps of: defining an abstract location object 
in said object oriented environment; defining a location 
subclass of said abstract object having implementation 
logic for server representations in said object oriented 
environment; and associating a plurality of servers in 
said object oriented environment with said location sub- 
class to set the scope of location for searches for factory 
objects. 

According to a second aspect, the invention pro- 
vides an apparatus for creating an interface for defining 
the scope for searches for object factories in an object 
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oriented environment, including: means for defining an 
abstract location object in said object oriented environ- 
ment; means for defining a location subclass of said ab- 
stract object having implementation logic for server rep- 
resentations in said object oriented environment; and 
means for associating a plurality of servers in said object 
oriented environment with said location subclass to set 
the scope of location for searches for factory objects. 

This invention according to a preferred embodiment 
provides a method and apparatus for controlling a scope 
of location for a FactoryFinder object. FactoryFinder ob- 
jects provide a standard way for a program to find a fac- 
tory object which is used to create another object in an 
object-oriented system. The scope of location may be a 
specific machine, all machines within a work group, all 
object server processes running under a particular op- 
erating system, etc. An abstract location interface is pro- 
vided which can be subclassed to provide a location ob- 
ject. The abstract location interface is inherited by all 
other location interfaces. The abstract interface intro- 
duces a method that is used to return all the servers 
within the scope defined by the location object. The lo- 
cation object, at a minimum, provides methods for re- 
turning a list of servers indicating the full scope of the 
location, for returning a boolean value of TRUE or 
FALSE for an inquiry about a specific server, and for cre- 
ating a new location object and registering servers that 
result from an intersection/union of the servers encap- 
sulated by the current location and another location. 

Brief Description of the Drawings 

Figure 1 is an illustrative embodiment of a hetero- 
geneous distributed data processing system in ac- 
cordance with the present invention; 

Figure 2 is a block diagram of a computer/worksta- 
tion within the distributed data processing system 
in Figure 1; 

Figure 3 is a pictorial representation of the general- 
ized software configuration of two nodes within a 
heterogeneous distributed object-oriented comput- 
ing environment; 

Figure 4 depicts a class diagram illustrating the 
class relationship between an OMG FactoryFinder 
object and a Location object; 

Figure 5 illustrates a pictorial representation for ac- 
cessing a Location object by a Client object from a 
FactoryFinder object when a Client object invokes 
the findjactories method on a FactoryFinder ob- 
ject; 

Figure 6 illustrates a sequence diagram illustrating 
how a FactoryFinder object utilizes a Location ob- 
ject to control the scope of its methods; 



Figure 7 is a flow diagram for defining a Location 
object and using it to define the location scope for 
various FactoryFinder objects; 

5 Figure 8 is a Location object illustrating the potential 
methods in the Location object; and 

Figure 9 is a Location object illustrating the basic 
characteristics (minimum) of the Location object. 

10 

Detailed Description of the Embodiments 

This invention according to a preferred embodiment 
provides a method and apparatus for a Location object 
is contained within an Object Management Group (OMG) 
FactoryFinder object. Location objects are used to de- 
fine the scope of location within which an object exists. 
To a user, the scope of locations may be a specific ma- 
chine, all the machines within a work group, all object 
20 server processes running under a particular operating 
system, etc. To a distributed object system, a location is 
a very specific concept, directly tied to the Object Re- 
quest Broker (ORB) implementation for the system. For 
example, a particular ORB might define the location 
25 where an object exists as an object server process iden- 
tified by a particular unique implementation identifier. It 
is the job of the location object to bridge the gap between 
the user's idea of location, and the distributed object 
systems' idea of location. For example, a location object 
30 might be used to define all of the machines in a work 
group (user's view), while also being able to provide a 
list of all of the unique implementation identifiers for all 
of the object server processes that exist within that 
scope (distributed object system's view). The invention 
35 will now be described in further detail using Figures 1 -9. 
A representative hardware environment where this 
invention may be practised is depicted in Figure 1 , which 
illustrates a pictorial representation of a distributed data 
processing system 8. As illustrated, data processing 
40 system 8 contains a plurality of networks, including local 
area networks (LAN) 10 and 32, each of which prefera- 
bly includes a plurality of individual computers 12 and 
30, respectively. One skilled in the art will appreciate that 
a plurality of workstations coupled to a host processor 
45 may be utilized for each such network. As is common in 
such data processing systems, each computer 12 and 
30, may be coupled to a storage device 1 4, and a printer 
16. 

Data processing system 8 further includes one or 
so more mainframe computers, such as mainframe com- 
puter 18, which may be preferably coupled to LAN 10 
by means of a communication link 22. Mainframe com- 
puter 18 is preferably coupled to a storage device 20, 
which serves as remote storage for LAN 10. LAN 10 is 
55 also coupled via communications link 24 through com- 
munications controller 26 and communications link 34 
to gateway server 28. Gateway server 28 is preferably 
a workstation which serves to link LAN 32 to LAN 1 0 via 
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communications link 35. As understood by one skilled 
in the art, data processing system 8 additionally includes 
unillustrated gateways, routers, bridges, and various 
other network hardware utilized to interconnect the seg- 
ments of data processing system 8. 

Referring now to Figure 2, there is shown a pictorial 
representation of a workstation, having a central 
processing unit 40, such as a conventional microproc- 
essor, and a number of other units interconnected via a 
system bus 42. The workstation shown in Figure 2, in- 
cludes a Random Access Memory (RAM) 44, Read Only 
Memory (ROM) 46, an I/O adapter 48 for connecting pe- 
ripheral devices such as disk unit 43 to the bus, a user 
interface adapter 52 for connecting a keyboard 47, a 
mouse 53, a speaker 54, a microphone 49, and/or other 
user interface devices such as a touch screen device 
(not shown) to the bus, a communication adapter 45, for 
connecting the workstation to a data processing network 
and a display adapter 51, for connecting the bus to a 
display device 50. The workstation, in the preferred em- 
bodiment, has resident thereon the OS/2 operating sys- 
tem and the computer software making up this invention 
which is included as a toolkit. One skilled in the art will 
appreciate that the procedures of this invention may be 
in the form of a computer program product on a compu- 
ter readable medium, which may be temporarily or per- 
manently loaded on the workstation in disk storage 43, 
floppy diskette 41 , or RAM 44. 

With reference now to Figure 3, there is illustrated 
a pictorial representation of the generalized software 
configuration of two nodes 56 and 57 within a heteroge- 
neous distributed computing environment (HDCE), 
such as data processing system 8. As illustrated, nodes 
56 and 57, which can comprise two of computers 12 
within data processing system 8, execute software un- 
der the control of possibly diverse operating systems 60 
and 65, respectively. Although diverse operating sys- 
tems may be utilized by nodes 56 and 57, intercommu- 
nication between nodes 56 and 57 via network 66 is fa- 
cilitated by network transport layers 59 and 64, which 
can comprise Transport Control Protocol/Interface Pro- 
gram (TCP/IP), for example. The scftware configura- 
tions of nodes 56 and 57 further comprise a distributed 
object environment 58 and 63 including objects A, B, C, 
and D. To illustrate the interaction of objects A-D within 
distributed object environment 58 and 63, assume that 
object A invokes a method on objects B and C, passing 
object D as a parameter, and that objects B and C be- 
long to the same class. If object A calls object B, a local 
object, all of the interaction between objects A, B, and 
D occurs within the same local process and is controlled 
strictly by the dispatching and reference mechanisms of 
the local process. On the other hand, if object A calls 
object C, a remote object, the call is directed to object 
C proxy, which interacts with marshalling code 61 and 
transport framework 62 to package the call parameters 
intoa message having aformat suitable for transmission 
over network 66. In response to receipt of the message 



at node 57, network transport 64 passes the message 
to transport framework 67 and marshalling code 68, 
which demarshals the parameters to reconstruct the call 
of object C. Thereafter, an object D proxy is created and 
5 object C is called in the same manner as if object C was 
local to object A. Any requests from object C to object 
D are similarly handled through object D proxy. As can 
be seen from this description of a distributed object en- 
vironment, an object can transparently interact with oth- 
10 er objects within the distributed object environment with- 
out regard to whether the other objects reside at a local 
or remote node or whether the objects are within the 
same process. 

Referring now to Figure 4, there is shown an asso- 
15 ciation 70 between a FactoryFinder object 72 and a Lo- 
cation object 76. The FactoryFinder object 72, contains 
"zero" or "one" Location object 76. The Location object 
76, may be contained by any number ("zero" to "N") of 
FactoryFinder objects 72. The Location interface is ab- 
20 stract and is designed to be subclassed. 

With reference to Figure 5, there is shown a dia- 
gram 80 illustrating the flow between objects when a Cli- 
entObject 82 invokes a find_factories method 100, on 
a FactoryFinder object 84 that has a LocationA object 
25 86 registered with it. The Client Object 82 invokes the 
find_factories method 1 00 on the FactoryFinder object 
84. The FactoryFinder object 84, invokes the 
list_server_ids method 1 1 0 on the LocationA object 86, 
which is a location object that is registered with the Fac- 
30 toryFinder object 84, via the set_location_scope meth- 
od 104. LocationA object 86, returns the list of servers 
112 that it represents to the FactoryFinder object 84. 
The FactoryFinder object 84, searches for factory ob- 
jects that match the specification provided by the Clien- 
ts tObject 82. Only factory objects that reside on a server 
returned by the LocationA object 86 are considered 
(those returned by 112). A list of factories 98 that reside 
with the location scope of LocationA 86, and meet the 
client requirements are returned to the ClientObject 82 
40 by the FactoryFinder object 84. 

Turning now to Figure 6, there is shown a sequence 
diagram illustrating how a FactoryFinder object utilizes 
a Location object to control the scope of its methods. 
The FactoryFinder object find_factories method is re- 
45 stricted to the scope boundaries as set by the Location 
object registered with it. For the purpose of this inven- 
tion, registration means "contained by". As a result of 
the restriction, the fi nd_f actor ies method will only con- 
sider factory objects that are able to create object in- 
50 stances on the server registered with the Location ob- 
ject. With reference to Figure 6, a ClientObject invokes 
the find_factories 1 30 method on a FactoryFinder ob- 
ject that has a Location object registered with it. The 
find_factories method passes in a Key parameter that 
55 specifies the type of object to create, as well as various 
other pertinent pieces of information relative to the fac- 
tory search, depending on the implementation of the 
FactoryFinder. The FactoryFinder invokes the 



25 



30 



35 



40 



45 



50 



4 



6/7/2010, EAST Version: 2.4.1.1 



7 



EP0 841 618 A2 



8 



list_server_ids method 132, on the LocationA object 
registered with it in order to obtain a list of servers 1 34, 
that define the scope of the findjactories operation. The 
FactoryFinder performs any internal processing neces- 
sary to build up parameters 1 36 for the factory search 
incorporating the location information retrieved. The 
FactoryFinder object interacts with the search vehicle 
138, passing in the required parameters, in order to lo- 
cate the factories that meet the requirements. The Fac- 
tory search mechanisms return the factories located 140 
to the FactoryFinder object. In this diagram, two factory 
objects (fl, f2) are found within the location scope bound- 
aries that met all of the ClientObject's requirements. The 
two factory objects are returned to the client 1 42 to sat- 
isfy the ClientObject's requirement by the FactoryFinder 
object. 

Referring now to Figure 7, there is shown a flow di- 
agram for defining a Location object and using it to de- 
fine the location scope for various FactoryFinder ob- 
jects. The procedure begins at step 150, and proceeds 
immediately to block 152, where the procedure defines 
an abstract Location object with the standard behav- 
iours that will be common to all subclasses of location. 
No implementation details needs to exist at this level 
since most of the logic will reside at the subclass level. 
At block 1 54, subclasses of the abstract location are de- 
fined in order to provide an implementation for the var- 
ious server representations that exist in the environ- 
ment. For example, there may be a subclass that de- 
fines server IDs as strings, while another subclass may 
deal with server representations as objects. At block 
1 56, servers are registered with the location subclasses 
in order to define the scope of each location. The regis- 
tration process associates the scope with a Location ob- 
ject, but as appreciated by one skilled in the art, there 
are many other options available other then registration 
that may be defined by the implementer. The central 
point of the registration process is that a mechanism ex- 
ists that sets the scope of the location subclass such 
that the location subclass will be able to list the servers 
identified as its' scope. At block 158, the location sub- 
class is registered with a FactoryFinder object in order 
to define the scope for various activities performed by 
the FactoryFinder object. A location subclass may be 
registered with any number of FactoryFinder objects. 

Turning now to Figure 8, there is shown a Location 
object 160 and the characteristics that are desirable in 
a Location object that uses a registration mechanism to 
define servers as part of the scope of the location sub- 
class. The internal storage mechanism 178, utilized by 
the Location object 160 to maintain the list of servers 
with the Location object is implementation specific and 
will be defined by the specialized subclasses. For ex- 
ample, server identifications for one location subclass 
may be represented as strings, and another by objects. 
The methods defined in Figure 8 are general to all of the 
subclasses utilizing a registration mechanism. Howev- 
er, the methods may be defined at the abstract level and 



implemented at the subclass level. An example of the 
methods for a Location object 1 60 utilizing a registration 
mechanism are as follows: 

5 1) list_servers 164: This method returns a list of 
servers registered with the Location object. 

2) add_server 1 74: This method registers the serv- 
er passed in with the Location object. 

3) remove_server 162: This method terminates 
10 the registered status of the server passed in to the 

Location Server 160. 

4) add_servers 166: This method registers the 
group of servers specified with the Location Object 
160. 

is 5) remove_servers 168: This method terminates 
the registration status of the group of servers spec- 
ified. 

6) is_server_in_location 176: This method returns 
a boolean value of TRUE if the specified server is 

20 registered with the Location Object 160, and a 
boolean value of FALSE if it is not. 

7) location_union 172: This method creates a new 
Location object, and registers the servers that are 
the result of a union of the servers registered with 

25 the current location and another location, as spec- 
ified by the user. 

8) locationjntersection 1 70: This method creates 
a new Location object, and registers the servers 
that are the result of an intersection of the servers 

30 registered with the current location and another lo- 
cation, as specified by the user. 

As appreciated by one skilled in the art, additional 
methods may be added to the Location object 160, de- 
35 pending on the environment structure and the needs of 
the users. 

Referring now to Figure 9, there is illustrated the ba- 
sic characteristics of a Location object 180, containing 
the minimum set of methods regardless of whether a 

40 registration mechanism is utilized. All location objects 
should provide, at a very minimum, a listing mechanism 
such as the list_servers method 182, that indicates to 
the caller the location scope of the Location object 1 80. 
Other convenience methods such as location_union 

45 188, locationjntersection 184, and 
is_server_in_location 186 are useful for providing in- 
formation to the user. 

While the invention has been described with re- 
spect to a preferred embodiment thereof, it will be un- 

50 derstood by those skilled in the art that various changes 
in detail maybe made therein without departing from the 
spirit, scope, and teaching of the invention. The Location 
object of this invention offers a broad range of useful- 
ness in that it may be utilized by any object that would 

55 like to restrict operations to a specified scope boundary. 
For example, the Location object is useful in adminis- 
trative tasks since it provides administrators with a 
mechanism for resource control by restricting where ob- 
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jects can be created to the server group defined by a 
Location object. The ability to control the behaviour of 
objects by utilizing a Location object to restrict method 
activities to a specific scope is highly desirable in large 
distributed environments. The concept is extremely 
powerful, andean be applied in a variety of ways to meet 
the business needs of users. 



Claims 

1. A method, implemented in a computer system, for 
creating an interface for defining the scope for 
searches for object factories in an object oriented 
environment, including the steps of: 

defining an abstract location object in said ob- 
ject oriented environment; 

defining a location subclass of said abstract ob- 
ject having implementation logic for server rep- 
resentations in said object oriented environ- 
ment; and 

associating a plurality of servers in said object 
oriented environment with said location sub- 
class to set the scope of location for searches 
for factory objects. 

2. The method of claim 1 , wherein the step of associ- 
ating a plurality of servers includes the step of: 

registering said plurality of servers with said lo- 
cation subclass. 

3. The method of claim 1 or claim 2, wherein the step 
of associating a plurality of servers includes the step 

of: 

registering a subclass with a selected Factory- 
Finder object to set the scope of said Factory- 
Finder. 

4. The method of any one of claims 1 to 3 : wherein the 
step of defining an abstract location object further 
includes the step of: 

defining a location object having a listing mech- 
anism for said plurality of servers in said object 
oriented environment. 

5. An apparatus for creating an interface for defining 
the scope for searches for object factories in an ob- 
ject oriented environment, including: 

means for defining an abstract location object 
in said object oriented environment; 



means for defining a location subclass of said 
abstract object having implementation logic for 
server representations in said object oriented 
environment; and 

5 

means for associating a plurality of servers in 
said object oriented environment with said lo- 
cation subclass to set the scope of location for 
searches for factory objects. 

10 

6. The apparatus of claim 5, wherein the means for 
associating a plurality of servers includes: 

means for registering said plurality of servers 
is with said location subclass. 

7. The apparatus of claim 5 or claim 6, wherein the 
means for associating a plurality of servers in- 
cludes: 

20 

means for registering said subclass with a se- 
lected FactoryFinder object to set the scope of 
said FactoryFinder. 

25 8. The apparatus of any one of claims 5 to 7, wherein 
the means for defining an abstract location object 
further includes: 

means for defining a location object having a 
30 listing mechanism for said plurality of servers 

in said object oriented environment. 

9. A computer program product comprising a compu- 
ter readable storage medium having computer 
35 readable program logic recorded thereon for creat- 
ing an interface for defining the scope for searches 
for object factories in an object oriented environ- 
ment, the computer program logic including: 

40 means for defining an abstract location object 

in said object oriented environment; 

means for defining a location subclass of said 
abstract object having implementation logic for 
45 server representations in said object oriented 

environment; and 

means for associating a plurality of servers in 
said object oriented environment with said lo- 
50 cation subclass to set the scope of location for 

searches for factory objects. 
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